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This  report  consists  of  an  "In-depth  Assessment  of  the 
Status  of  Distributed  Data  Bases  and  Potential  U.S.  Navy 
Requirements"  with  two  accompanying  bibliographies.  Following 
a .discussion  of  the  distributed  computer  systems  technology 
and  its  very  considerable  significance,  the  report  proceeds 
to  point  out  the  implications  of  adoption  of  this  decentralized 
approach.  Proceeding  further,  the  report  concludes  that  the 
question  of  distributed  processing  applications  to  Navy  strategic 
and  tactical  requirements  must  be  approached  from  a more  funda- 
mental basis  than  system  conversion.  We  recommend  an  analysis 
of  Navy  requirements  from  a functional  frame  of  reference,  during 
the  course  of  which  the  functions  and  activities  necessary  to 
fulfill  the  Navy's  missions  and  objectives  under  various  modes 
of  operation  must  be  studied  and  specified.  When  completed,  this 
analysis  will  serve  as  a basis  from  which  to  move  directly  to 
decisions  as  to  areas  for  which  distributed  systems  are  appropri- 
ate as  well  as  those  areas  for  which  retention  of  more  centralized 
system  control  is  desirable. 
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^This  report  consists  of  an  "In-depth  Assessment  of  the 
Status  of  Distributed  Data  Bases  and  Potential  U.S.  Navy 
Requirements"  with  two  accompanying  bibliographies.  Following 
a discussion  of  the  distributed  computer  systems  technology 
and  its  very  considerable  significance,  the  report  proceeds 
to  point  out  the  implications  of  adoption  of  this  decentralized 
approach.  Proceeding  further,  the  report  concludes  that  the 
question  of  distributed  processing  applications  to  Navy  strategic 
and  tactical  requirements  must  be  approached  from  a more  funda- 
mental basis  than  system  conversion.  We  recommend  an  analysis 
of  Navy  requirements  from  a functional  frame  of  reference,  during 
the  course  of  which  the  functions  and  activities  necessary  to 
fulfill  the  Navy's  missions  and  objectives  under  various  modes 
of  operation  must  be  studied  and  specified.  When  completed,  this 
analysis  will  serve  as  a basis  from  which  to  move  directly  to 
decisions  as  to  areas  for  which  distributed  systems  are  appropri- 
ate as  well  as  those  areas  for  which  retention  of  more  centralized 
system  control  is  desirable. 
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Shared  and  valid  information  is  essential  whenever  one 
wishes  to  reduce  the  uncertainty,  risk  and  potential  cost 
involved  in  decision  making.  Data  Solutions  Corporation 
believes  that  this  axiom  is  especially  true  regarding  the 
Navy's  interest  in  distributed  data  base  technology.  We  are 
quite  concerned  with  the  present  tendency  for  the  supply 
caused  by  the  quick  development  of  data  base  technology  to 
drive  demand.  DSC  believes  that  such  a situation  unneces- 
sarily increases  uncertainty,  risk  and  cost  in  the  Navy 
Manager's  decision  function.  Consequently  we  have  targeted 
our  report  and  bibliography  so  that  the  generalist  managers 
can  "get  ahead  of  the  power  curve"  and  better  demand  the  supply 
of  distributed  data  base  technology  that  best  fits  their  real 
missions,  objectives  and  needs. 
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EXECUTIVE  SUMMARY 


In  recent  years  a radically  new  concept  and  approach  to 
automatic  data  processing  has  emerged.  Basically,  this  new 
approach  envisages  a de-emphasis  of  and  a departure  from  the 
currently  prevalent  centralized  computer  operations  and  a 
replacement  of  such  systems  by  decentralization  and  delegation 
of  function  to  the  component  elements  of  a system  of  lesser 
computers.  Such  decentralized  systems  are  frequently  referred 
to  as  distributed  systems.  The  purposes  of  this  paper  are  to 
analyze  the  current  status  of  distributed  systems  and  to  assess 
the  implications  of  such  systems  as  a prelude  to  addressing  the 
central  problem  created  by  this  new  technology,  which  can  be 
stated  as  follows:  "What  are  the  implications  of  this  new 
technology  for  the  U.S.  Navy  and  what  should  the  Navy  do  about 
it?" 


We  have  selected  three  specific  objectives  in  the 
preparation  of  this  report  and  accompanying  bibliographies. 

First,  our  target  group  is  Navy  management  personnel  who  have 
limited  computer  background.  Both  the  report  and  bibliographies 
are  written  with  this  consideration  in  mind.  Our  bibliographies 
are  especially  intended  to  provide  management  personnel  with 
the  basic  issues  regarding  distributed  data  base  technology  and 
with  a source  of  ready  reference  on  relevant  instructions. 
Furthermore,  the  material  cited  is  in  basic  and  understandable 
terminology.  Thus  we  are  attempting  to  provide  management 
personnel  with  a useful  key  to  the  technical  literature  that 
is  being  generated  at  this  time. 

Our  second  objective  is  to  persuade  Navy  management  to 
abandon  their  localized  single  problem  solution  approach. 

This  report  presents  the  reader  with  an  alternative  approach 
that  is  more  systematic.  Specifically  our  recommendation  is 
that  the  Navy  use  a functional  frame  of  reference  in  deciding 
whether  or  not  to  adapt  to  a distributed  data  base  (DDB) 
technology.  An  analysis  of  this  functional  approach  forms  the 
major  portion  of  this  study. 

This  functional  perspective  is  intended  to  serve  our  third 
objective.  DSC  consultants  believe  that  a dialogue  regarding 
software  management  must  be  initiated  in  the  Navy,  bringing 
together  Key  Navy  management  personnel  and  general  systems 
specialists  working  under  a common  taxonomy  of  problem  definition 
and  solution.  Section  V of  this  report,  "Solution  Strategies," 
identifies  precisely  what  steps  we  believe  should  be  taken  during 
the  course  of  this  dialogue.  Having  built  the  functional  frame 
of  reference,  the  next  step  of  selection  of  appropriate  computer 
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systems,  ranging  from  centralized  to  decentralized,  to  serve 
each  organizational  component  is  rendered  relatively  simple. 

The  resultant  total  system  structure  will  be  a harmonious 
blending  of  component  system  alternatives  each  best  suited  to 
its  own  requirements  while  at  the  same  time  forming  a coherent 
and  workable  part  of  the  whole. 

Recommendations ; 

1.  Identify  for  each  Navy  organization  its  essential  functions 

2.  Dissect  these  functions  into  activities 

3.  Identify  the  information  processing  requirements 

4.  Examine  distributed  data  base  network  alternatives 

5.  Draw  up  training  and  skill  development  plan 


INTRODUCTION 


l. 


"The  rate  ot  growth  of  the  computer  industry  since  its 
embryonic  stages  in  the  late  1940's  has  been  nothing  short  of 
phenomenal."  Thus  Captain  Jan  Prokop,  SC,  USN,  characterized 
the  growth  of  computer  usage  over  the  past  thirty  years  in 
his  opening  article  for  the  excellent  book  Computers  in  the 
Navy , of  which  he  is  editor.--  Indeed,  it  is  probable  that 
the  computer  industry  is  the  fastest  growing  industry  in  the 
country.  During  this  period,  the  computer  has  gone  through 
several  major  changes  or  transformations  in  its  development. 

Each  trans form.it. ion  has  resulted  in  the  emergence  of  what  is 
generally  referred  to  as  a new  generation  of  computers.  The 
most  recent  of  these  major  transformations,  the  emergence  of 
the  smaller  and  less  expensive  computers  which  have  permitted 
a considerable  decentralization  of  computer  usage,  may  be  the 
most  important  and  most  far-reaching  of  all.  It  is  this  most 
recent  transformation,  and  its  implications,  that  constitute 
the  purpose  of  this  report. 

The  very  first  computers  were  large  and  complicated 
machines  dedicated  to  one  application  or  purpose  only.  They 
were  also  very  expens ive--so  expensive  that  several  prospective 
users  often  got  together  to  acquire  one  for  their  mutual  use. 

This,  of  course,  led  to  considerable  conflict  as  to  what  purpose 
the  computer  would  be  used  for.  This  situation  led  directly 
into  the  second  generation  of  computers,  which  were  larger  and 
more  complex  machines  that  could  be  used  for  several  applications 
at  once.  This  concurrent  utilization,  called  multiprogramming, 
required  very  complicated  operating  systems  to  schedule  the 
various  tasks.  During  this  period  we  saw  the  development  of 
the  specialized  data  processing  departments,  which  grew  up  in 
order  to  cope  with  the  problems  inherent  in  multiprogramming 
operations.  The  third  generation  of  computers,  which  came  in 
the  late  1960's,  was  really  only  an  expansion  or  elaboration  of 
the  second,  featuring  larger  and  more  powerful  machines  and 
larger  and  more  complex  support  structures.  The  data  processing 
departments  grew  and  became  staffed  by  specialists  who  each  knew 
his  or  her  own  role  in  the  overall  process  but  who  were  removed 
from  the  overall  picture.  This  period  marked  the  high  point  in 
the  centralization  of  computer  growth  and  development:  larger, 
centrally  located  computers  handled  by  large  central  departments. 
This  system  was  complex  and  top-heavy,  overloaded  with  specialized 
jobs,  and  production  costs  kept  getting  higher.  Furthermore, 
management  was  completely  removed  from  the  processing  of  infor- 
mation and  had  minimum  contact  with  its  processing  department, 
which  was  regarded  as  a necessary  evil.  As  cost-effectiveness 
deteriorated,  the  acquisition  of  additional  computers  was  often 
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regarded  as  a panacea,  but  this  led  to  the  problem  that  these 
computers  would  be  programmed  differently  and  would  not  relate 
to  existing  programs.  This  situation  led  to  a great  push  for 
standardization,  so  that  all  one's  computerized  assets  could 
relate  to  one  another,  although  this  standardization  often  proved 
to  be  extremely  difficult  and  indeed  almost  impossible  in  actual 
practice  without  the  radical  alteration  or  even  abandonment  of 
existing  computer  programs.  The  entire  system  was  becoming  almost 
intolerably  unwieldy. 

It  was  into  this  kind  of  environment  that  the  smaller  and 
less  expensive  minicomputers  came  on  stage  in  the  early  1970 's. 
Offspring  of  the  space  program,  these  new  computers  were 
revolutionary  because  they  were  now  available  to  a much  larger 
number  of  potential  users  and  in  larger  quantities.  However, 
although  the  cost  of  the  hardware  was  now  going  down  (between  1965 
and  1975  the  relative  cost  of  hardware  declined  from  about  75^  , 
to  about  25%  of  the  total  cost  for  computer  systems  support) ,— 
the  total  cost  of  operating  computer  systems  continued  to  go  up 
because  of  the  tremendous  need  for  more  programming--more 
sof tware--for  all  the  computers,  and  for  people  to  develop  the 
software.  Software  costs  are  largely  determined  by  personnel 
costs.  The  demand  for  software  people  with  expertise  became 
almost  desperate,  and  many  poorly  trained  and  marginally 
competent  personnel  sold  their  services.  This,  of  course,  led 
to  badly  designed  and  ineffective  programming , which  further 
exacerbated  existing  problems  and  tensions. 

The  minicomputer  was  one  of  two  innovations  necessary  to 
permit  escape  from  the  massive  centralized  complexity  that 
the  computerized  world  was  becoming.  What  was  still  needed  was 
a way  of  breaking  down  the  single  centralized  system  into  a 
system  of  systems,  so  that  complexity  could  be  gradually  reduced, 
with  the  advent  of  the  switching  capability,  this  became  possible. 


1/ 


Prokop,  Jan,  Fd.,  "Computers  in  the  Navy,"  Naval  Institute  Press, 
Annapolis,  Maryland,  1976,  p.  8. 

2/ 

— Haak,  RADM  Frank  S.,  "Brainwave  vs.  Hardware,  m Prokop, 
op.  cit. , p.  10. 
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II.  DISTRIBUTED  COMPUTER  SYSTEMS  TECHNOLOGY 


At  some  point  in  the  life  of  any  system  it  becomes  too 
large  to  be  sustained  by  a single  control.  Responsibilities 
must  be  delegated,  and  tasks  divided.  When  this  happens,  each 
task  becomes  less  complicated,  easier  to  focus  upon,  and  nine 
times  out  of  ten,  easier  to  deal  with.  In  the  world  of  computers, 
this  meant  the  creation  of  a network  or  series  of  computers, 
each  performing  component  tasks  or  steps  that  are  part  of  the 
whole,  connected  together  by  a communications  system  so  that 
the  components  can  "talk"  to  each  other.  As  we  have  seen,  the 
concept  of  the  "system  of  computers"  could  become  a reality  with 
the  advent  of  two  developments:  the  minicomputer  and  switching 
systems . — 


The  significance  of  the  now  fairly  widespread  availability 
of  the  relatively  low  cost  system  of  computers  is  almost 
incalculable.  It  permits  the  correction  of  virtually  all  of 
the  weaknesses  and  vulnerabilities  that  had  come  to  typify  the 
typical  computer  operation.  For  one,  the  sheer  physical  limi- 
tations of  the  great  central  computer  could  be  overcome,  by 
having  several  computers  working  together  do  the  job  of  one. 

At  least  as  significant  is  the  fact  that  the  complexity  of 
the  software  can  now  be  overcome:  a number  of  relatively  simple 
programs  can  take  the  place  of  a single  massive  hierarchically 
structured  program.  This  simplification  of  programs  also  means 
fewer  errors,  and  less  "debugging"  time.  The  fourth  important 
advantage  is  that  the  whole  operation  does  not  depend  upon  one 
key  computer;  if  one  of  the  minicomputers  in  the  system  breaks 
down,  it  can  readily  be  replaced  or  bypassed.  The  new  systems  of 
computers  have  every  advantage:  less  cumbersome  and  complex, 
much  easier  to  work  with,  requires  less  complicated  software,  can 
be  serviced  by  fewer  people  and  is  much  less  expensive. 

Many  new  terms  are  being  used  in  the  computer  industry  as 
a result  of  the  present  push  towards  decentralization  of 
information  processing.  A currently  popular  term  for  the  system 
of  computers  that  we  have  been  talking  about  is  the  Distributed 
Computer  System.  Such  a system  was  defined  at  the  Distributed 
Processing  Workshop  at  Brown  University  (August  1977)  sponsored 
by  the  Office  of  Naval  Research  as  follows: 

"A  Distributed  Computer  System  is  a collection  of 
processing  elements  (of  any  size:  micro  to  maxi)  which 
are  logically  and  physically  interconnected  with  a 
decentralized  system-wide  control  for  the  cooperative 
execution  of  single  applications." 
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This  definition  is  rendered  somewhat  clearer  by  providing  a 
further  definition  of  a centralized  system,  and  therefore,  what 
a distributed  system  is  not : 

’•In  a totally  centralized  configuration,  nil  three 
functions — information  processing,  network  processing, 
and  data  base  process.ing--cxi.st  at  a single  site.  This 
site  provides  all  resources  required  by  the  terminal 
users  in  the  surrounding  network.  In  a totally 
distributed  configuration,  each  of.the  throe  functions 
exist  in  more  than  one  location."-' 

In  short,  what  the  distributed  system  does  is  to  break  up  both 
hardware  and  software  into  subassemblies  and  link  them  by 
communications . 

On  the  face  of  them,  distributed  systems  arc  so  attractive 
that  consumers  are  rushing  pell-mell  to  acquire  them.  Initial 
reticence,  occasioned  by  apprehensions  that  going  this  new  route 
would  mean  junking  a lot  of  existing  computers  and  programs,  has 
been  largely  overcome  by  the  realization  that  you  do  not  junk 
your  old  computer,  you  merely  add  some  simple  inexpensive 
computers  to  work  with  it  and  lessen  its  load.  Furthermore, 
although  certainly  most  existing  programs  had  to  be  either 
drastically  modified  or  abandoned,  their  replacement  programs 
were  simpler,  easier  to  build,  less  confusing,  and  not  all  that 
expensive. 

In  spite  of  the  undeniable  attractiveness  of  the  distributed 
systems,  Data  Solutions  has  some  distinct  reservations  about  the 
across-the-board  desirability  of  such  systems  in  all  situations. 

We  are  nervous  because  we  are  aware  of  the  truth  that  techno- 
logical innovation  serves  as  a forcing  function  in  a gadget-oriented 
society:  there  is  great,  pressure  toHbe  modern  and  up-to-date,  to 

take  on  the  latest  fashion.  We  recognize  that  the  new  distributed 
technology  is  of  very  great,  significance,  and  yet.  we  fear  that 
uncoordinated  acquisition  and  implementation  of  this  technology 
could  have  adverse  consequences  for  the  Navy.  Our  reservations 
are  discussed  in  the  following  section  entitled  "Implications  of 
Change . " 


3Alopper,  Grace  M. , "David  and  Goliath,"  in  Prokop,  op.  cit. , 
pp.  64-65. 

--^Becker,  Hal  B. , "Network  Securi  ty  in  Distributed  Dat  a 
Processing,"  Data  Communications , August  1977 , pp.  33-39* 
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IMPLICATIONS  OF  CHANGE 


Early  success  in  distributed  systems  by  already  decentral- 
ized organizations  will  tempt  others  to  mimic  without  fully 
understanding  the  impact  of  change.  For  those  information 
systems  which  become  decentralized  with  the  oncoming  technology 
shift  to  distributed  information  systems,  the  host  organizations 
will  feel  increasing  pressure  to  shift  from  centralized  control 
to  a more  decentralized,  autonomous  control  process.  Each 
organizational  entity  could  increasingly  acquire  the  capability 
to  respond  more  quickly  to  external  or  internal  stimuli.  If 
this  increase  in  response  time  was  not  compatible  with  the 
remainder  of  the  organization,  it  could  prove  detrimental  to 
the  stability,  missions  and  objectives  of  other  entities  as 
well  as  the  overall  organization.  Since  information  is  the 
major  component  of  the  control  mechanism  of  the  organization, 
decentralization  or  distribution  can  bring  with  it  the  following 
dangers : 

• Misinformation 

• Duplication  of  effort 

• Power  struggles  concerning  goal  attainment 

• Dysf unctional  competition 

• Misinterpretation  of  perspective 

• Security  compromise,  sabotage,  embezzlement. 

Centralized  control  of  the  organization  becomes  more  difficult 
because  of  the  various  level  and  function  perspectives  on 
information  created  by  distributed  organizational  problem-solving 
capabilities.  Organizational  structure  and  process  will  have  to 
change.  New  architectures  would  bo  required  as  well  as  enabling 
structures,  processes  and  resoprces  to  move  from  the  "as  is"  to 
the  "should  be"  configuration.— 

We  believe  that  the  management  goal  of  control  is  essential 
in  any  organization,  and  particularly  in  the  Navy.  However, 
the  degree  of  control  that  is  necessary,  or  even  advisable,  in 
different  operational  areas  may  vary  considerably.  We  conceptu- 
alize five  general  types  of  control: 

• Technological : hardware  and  software 

• Structural : policies  and  procedures 
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• Resource ; information  and  funding 

• Personnel : management  and  training 

• Performance : standards  and  productivity  measures 

The  degree  of  centralization  of  control  in  each  of  these  five 
areas  that  is  necessary  and  desirable  will  vary  in  each  organi- 
zation and  will  also  vary  from  organization  to  organization. 

What  degree  of  control  is  deemed  most  efficient  and  effective 
in  each  control  area  is  determined  by  a number  of  decision 
factors,  i.e~,  situation,  function,  time  frame,  organizational 
objectives.—  All  of  these  factors  must  be  considered  when 
management  examines  each  of  the  five  areas  listed  above  in  which 
varying  degrees  of  control,  ranging  from  complete  centralization, 
the  monolithic  pyramidal  structure,  at  one  extreme,  to  complete 
decentralization,  in  which  each  basic  component  element  makes 
its  own  decisions  for  itself  without  any  upper  echelon  review, 
at  the  other  extreme. 

The  basic  purpose  of  any  information  system  is  to  get  the 
information  that  is  needed  by  any  and  all  users  in  an  organization 
(whether  they  be  human  or  mechanical  users)  to  get  his  or  her 
(or  its)  job  done  in  a reasonable  period  of  time.  The  real 
significance  of  the  new  technology  is  that  more  options  arc  now 
available  so  that  information  systems  can  be  tailored  to  satisfy 
the  requirements  of  the  organization. 

Every  technology  has  its  own  inherent  logic.  Therefore, 
new  technology  over  time  will  have  a revolutionary  impact  in 
that  it  exposes  the  user  slowly  but  surely  to  an  entirely  new 
logic  of  dealing  with  the  environment.  Logics  of  coping  in  a 
centralized  or  a decentralized  information  system  are  different. 
External  pressure,  however,  forces  innovation  of  new  technologies 
even  though  the  organization  is  not  capable  of  implementing  them. 
These  pressures  should  and  can  be  dealt  with  in  an  orderly 
manner  if  the  organization  will  begin  to  look  at  the  missions 
and  objectives  together  with  the  constraints  and  develop  a set 
of  requirements  under  which  information  systems  will  be  configured. 
This7.is  basically  a restatement  of  the  top  down  design  philoso- 
phy.— The  implementation  of  such  a philosophy  is  made  easier, 
but  not  solved,  with  the  increasing  options  of  hardware  configu- 
ration. The  problem  of  designing  and  developing  enabling 
information  systems  within  a given  organization  still  remains. 

5 / 

—Burns,  E.  J.  and  Proctor,  J.  H. , "Sistemi  e Amministrazione, " 
in  Paradigmi  a Societa,  Milano,  Franco  Angoli  Editore,  1976. 

— ^Proctor,  J.  H.  and  Lassiter,  W.  E. , "Prediction  of  Young  U.S. 
Naval  Officer  Retention,"  Personnel  Psychology,  Vol.  29.  no.  4. 

— ^Beer,  Stafford,  "Brain  of  the  Firm,"  Herder  and  Herder,  1972, 
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NAVY  REQUIREMENTS 


A.  The  Problem 

In  tho  previous  sections  of  this  report  we  have  looked 
in  a general  way  at  some  matters  that  ought  to  be  given 
consideration  concerning  the  advantages  and  disadvantages  of 
introducing  distributed  processing  and  data  bases.  The  time 
has  now  come  to  ask  the  specific  question  "What  are  the  Navy 
requirements?" 

The  Navy's  informational  requirements  are  basically  divisible 
into  two  major  areas,  each  radically  different  from  the  other. 

On  the  one  hand  there  are  the  problem  categories  that  the  Navy 
has  in  common  with  the  civilian  world;  these  include  payroll, 
inventory  control,  record  keeping,  maintenance,  planning  and 
programming,  and  so  on.  Problems  of  this  kind  are  primarily  of 
the  non-real  time  variety,  and  can  be  dealt  with  by  utilizing 
off-line,  big  batch  type  computers  with  cost  effectiveness  being 
a major  consideration.  On  the  other  hand  there  is  a separate 
set  of  problem  categories  which  are  almost  unknown  in  the  civilian 
world  and  which  are  created  by  the  fact  that  the  Navy  must  be 
ready  to  fight--t.o  respond  or  to  move  instantly.  The  solution  of 
these  problems  requires  a completely  different  set  of  capabilities; 
tactical  on-line,  real  time  information  processing  in  which 
reliability  and  ruggedness,  with  redundancy  in  the  event,  of 
component  loss,  are  far  more  important  considerations  than  cost 
effectiveness.  There  is,  between  these  two  major  areas,  an  almost 
total  dichotomy  of  perspectives.  Not  only  are  the  information 
requirements  of,  for  example,  a Navy  pilot  and  a comptroller  so 
different,  that  they  seldom,  if  ever,  would  have  any  common  interest 
in  information,  but  they  are  even  further  separated  one  from  the 
other  by  the  different  sets  of  circumstances  under  which  infor- 
mation must  come  to,  and  emanate  from,  them. 

Lot  us  look  briefly  at  the  basic  requirements  of  the  tactical 
Navy,  uging  as  a point  of  departure  tho  Navy  Tactical  Data  System 
(NTDS)  First  of  all,  single  ship  capability  is  required; 

each  ship  must  be  self-sufficient.  Secondly,  however,  each 
combat  entity  must  bo  able  to  communicate  with  every  other; 
constant  liaison  is  required.  Hence  all  systems  must  be  com- 
patible. Thirdly,  because  speed  is  so  essential,  the  exchange 
of  information  must  occur  almost  instantaneously,  so  that  the 
human  operator  can  maki?  a decision  in  time.  Thus,  information 
must  be  exchanged  over  laigh  speed  data  links,  with  computers 
themselves  doing  the  communicating . 


All  of  the  foregoing  requirements  for  an  effective  modern 
command  and  control  system  recommend  the  employment  of  distrib- 
uted data  systems.  As  our  bibliography  (see  Annex  A)  makes 
clear,  there  is  no  dearth  of  information  concerning  such  systems. 
Yet,  although  there  exists  in  various  parts  of  the  Navy  a certain 
amount  of  distributed  processing  capability,  there  is  not  much 
system  to  this  decentralization.  The  current  state  of  distribu- 
tive processing  and  distributed  data  bases  in  the  Navy  can  in 
large  measure  be  attributed  to  problem  solving  on  a localized, 
single  problem  basis.  Consequently,  custom  designed  information 
systems  incompatible  in  both  hardware  and  software  with  other 
systems  abound.  This  problem  is  not  confined  to  information 
processing  only;  in  actuality,  the  total  ship  system  integration 
problem  is  becoming  more  difficult.  Difficulty  in  integration 
of  systems  is  a measure  of  the  difficulty  of  implementing  an 
overall  design  philosophy.  When  a new  weapon  system  or  ship 
program  is  funded  by  Congress,  with  the  result  that  a new  system 
procurement  office  is  formed,  yet  another  custom-designed,  incom- 
patible information  processing  system  is  likely  to  be  added  to  the 
Navy.  It  becomes  apparent  when  looking  at  the  existing  diverse 
weapons  systems  that  the  question  of  distributed  processing 
applications  to  Navy  strategic  and  tactical  requirements  must 
be  tackled  from  a more  fundamental  basis  than  system  conversion. 
This  shift  of  fundamental  basis  would  be  to  increase  emphasis  on 
analysis  of  Navy  strategic  and  tactical  requirements  in  a 

functional frame  of  reference.  Various  functions  and  activities 

necessary  to  fulfil  the  Navy's  missions  and  objectives  under 
various  modes  of  operation  must  be  studied  and  specified.  In 
order  to  accomplish  such  an  undertaking  for  each  proposed  new 
platform  or  weapons  system,  a common  framework  must  first  be 
established  under  which  such  an  analysis  can  proceed.  Navy 
instructions  for  embedded  computer  software  design  and  development 
provide  scant  "how  to"  help  in  this  area,  in  our  opinion.  This 
statement  is  supported  by  a review  of  the  list  of  pertinent 
Department  of  Defense  instructions  included  as  Annex  h to  this 
paper:  "U.S.  Navy  Computer  Software  Management  in  Weapons  System 

Acquisition:  A Selected  Bibliography." 

B.  Functional  Frame  of  Reference 


In  dealing  with  the  strategic,  tactical  and  business 
requirements  for  viable  information  systems  in  the  Navy,  whether 
one  is  utilizing  a centralized,  decentralized  or  Hybrid  approach 
to  system  design,  it.  is  necessary  to  create  some  problem-solving 
structure.  This  structure  can  be  called  a "functional  frame  of 
reference. " 
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The  Navy  is  a hierarchically-structured  organization  with  a 
chain  of  command  for  control  in  dealing  or  coping  with  the  various 
modes  of  Navy  operation  (wartime,  peacetime,  natural  disaster, 
etc.).  It  is  an  organization  changing  with  time  and  world 
situations  but  which  must  maintain  firm  continuous  control  of 
all  operations.  Chain  of  command  survival,  is  dependent  upon 
the  hierarchical  character  of  unit  organization.  Information 
processing  system  designers  contend  that  they  are  not  concerned 
with  changing  the  structure,  but  with  adopting  new  information 
technology  to  serve  the  approved  organizational  structure.  If 
distributed  processing  and  data  bases  are  implemented,  they  must 
be  supportive  of  organizational  functions.  Dut  the  order  in  which 
design  decisions  are  made  becomes  important.  Is  the  organizational 
structure  fixed,  and  functional  improvements  made,  or  are  functional 
improvements  nominated  with  resulting  organization  structure 
changes?  Centralized  computers  have  affected  Navy  organization 
functions  and  so  will  DDD . 

The  Navy  organizational  mission  structure  is  shown  in 
Figure  IV-1.  Navy  policy  directives  are  boundary  setting  in 
nature  in  that  they  define  most  often  the  restrictions  or 
constraints  imposed  on  decision-making.  This  is  contrasted 
with  other  policy  methods  which  may  dictate  the  day-by-day 
operating  decisions.  Navy  policy  guidance  permits  a great  deal 
of  freedom  for  the  decision  maker.  Missions  are  set  within 
the  overall  Navy  policy  constraints  and  result  in  specific 
objectives.  Missions  and  objectives  do  not,  however,  indicate 
action,  but,  instead  specify  the  desired  results.  Functions 
and  activities,  on  the  other  hand,  are  action  related  and  are 
performed,  hopefully,  in  the  attainment  of  the  desired  results 
(objectives,  missions) . It  is  interesting  to  note  that  this 
environment  encourages  freedom  to  convert  information  into 
action  based  upon  one's  own  interpretation  of  the  situation. 

This  probably  accounts  for  the  diversity  of  information 
processing  systems  in  the  Navy.  Each  manager  is  free  to  select 
and  call  for  the  information  determined  to  be  essential  or 
important,  set  forth  in  formats  designed  to  suit  his  or  her 
particular  functions  and  activities  within  existing  policy 
guidance. 

Figure  IV-2  illustrates  the  decision-action  environment. 
Information  activities,  either  automated  or  manual,  support  the 
decision  function.  The  decision  function  in  itself  could  be 
looked  at  as  an  information  conversion  process  in  which  inputs 
are  converted  to  actions.  One  of  the  important  inputs  is 
experience.  Experience  is  gained  through  feedback  either 
formal  or  informal  based  on  the  results  of  actions  taken  in 
meeting  objectives. 
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Figure  IV-1:  HIERARCFIY  OF  NAVY  ORGANIZATION  MISSION 

STRUCTURE 
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This  representation  of  the  decision-action  environment 
is  ideal.  The  fact  of  the  matter  is  that  delays  and/or  dis- 
tortions of  information  occur  throughout  this  process.  The 
result  is  that  incomplete  information  leads  to  decisions  which 
create  actual  results  which  often  differ  from  the  anticipated 
result.  This  leads  to  instability  and  uncertainty.  Managers 
often  look  to  automation  for  the  solution  but  the  conversion 
from  manual  to  automated  information  processing  may  not  solve 
this  problem.  It  may  amplify  it.  Likewise,  going  to  distributed 
processing  without  a proper  requirements  analysis  could  amplify 
existing  information  problems. 

A starting  point  would  be  to  look  at  the  organizational  levels 
in  the  Navy,  including  both  combat  and  combat  support  commands, 
from  a functional  interface  viewpoint  and  define  functions  which 
are  generically  suitable.  These  functions,  which  can  be  broadly 
categorized  as  internal  to  a given  platform,  intra-platform,  and 
external  (extra-Navy) , can  be  examined  for  each  platform,  system, 
and  subordinate  elements  in  various  situations  as  shown  in 
Figure  IV-3. 

Figure  IV-4  shows  an  example  of  information  activities  as 
related  to  functions.  In  this  figure,  various  information 
activities  are  listed  which  represent  a general  categorization  of 
subjects  which  must  be  addressed  in  any  information  processing 
requirements  analysis.  The  figure  does  not  attempt  to  show  the 
interactions  between  decision  functions  and  across  intra,  inter 
and  external  functions  categories.  It  should  be  noted,  however, 
that  they  do  exist  and  are  often  complex.  One  can  extend  this 
general  concept  through  all  functions,  from  budgeting  through 
deployment  of  weapons.  We  see  that,  while  it  is  a relatively 
simple  concept,  consistent  with  existing  instructions,  its 
advocacy  implementation  and  continued  sponsorship  in  light  of 
the  present  heterogeneous  Navy  information  environment  is  clearly 
problematical . 

C.  Data  Base  Management  Control 

Sizeable  though  the  task  may  be,  it  is  apparent  to  us  that 
Navy  management  must  begin  to  discuss,  delineate,  and  design 
specific  mechanisms  of  data  base  management  control.  The 
preceding  sections  of  this  paper  serve  to  identify  the  basic 
issues  that  Navy  management  might  consider  in  its  decision  to 
employ  distributed  data  base  technology.  We  have  also  indicated 
how  a manager  might  move  from  a localized  single  problem  solution 
approach  (incremental  model)  to  a functional  framework.  All 
of  these  issues  become  just  interesting  sidelights  to  daily 
management  decisions  unless  they  can  be  shown  to  serve  management 
objectives . 
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DSC  consultants  believe  that  the  management  objective  of 
control  is  essential.  We  have  conceptualized  above  five  general 
types  of  control  factors.  We  repeat  them  as  follows: 

• Technological 

• Structural 

• Resource 

• Personnel 

• Performance 

It  is  interesting  to  note  that  distributed  data  base 
technology  emphasizes  the  decentralization  of  computer  elements. 
Consequently  technological  variety  is  generated.  Furthermore, 
resource  variety  may  be  increased  if  the  demands  for  input  of 
information  is  increased  and/or  output  of  information  is  increased 
because  of  the  decentralization.  However,  in  other  control  areas, 
such  as  personnel  (and  management  in  particular) , a more 
centralized  degree  of  control  (with  less  variety)  is  probably 
indicated.  Hence,  there  are  variations  in  degree  of  control 
across  the  control  spectrum. 

How  can  we  arrive  at  a determination  of  the  optimum  degree 
of  centralization  or  decentralization  in  each  Navy  functional 
area  across  Navy  objectives  within  various  mission  areas?  Is  each 
so  different  that  each  is  considered  unique?  Are  there  no 
similarities  of  activities  within  functions?  If  an  incremental 
decision-making  approach  (localized  single  problem  solution 
approach)  is  used,  then  a manager  might  keep  experimenting  with 
coping  strategies  until  a satisfactory  solution  is  found  by 
design  or  chance.  This  minimizes  efficiency.  Also  effectiveness 
(compatibility  and  congruence  with  organizational  objectives)  may 
be  threatened  if  a "solution"  appears  to  be  initially  satisfactory 
but  over  time  becomes  incompatible  with  stated  operational  ob- 
jectives. Data  Solution  consultants  believe  that  the  amount  of 
time  and  energy  invested  in  the  incremental  decision-making  style 
is  usually  greater  than  the  benefits  accrued. 

That  is  why  we  advocate  a more  systematic  problem  solving 
approach  based  on  functional  analysis  and  mission/objective 
requirements.  Navy  managers  can  look  at  the  functional  re- 
quirements and  see  what  mix  of  control  strategies  (technology, 
structural,  resource,  personnel  and/or  performance)  optimizes 
efficiency  and  effectiveness.  Furthermore,  they  must  begin  to 
discuss  and  share  ideas  as  to  how  the  decision  factors  (situation, 
function,  time  frame,  organization  objectives  and  personel  intent) 
affect  these  control  strategies. 
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Another  reason  to  employ  this  concept  of  control  strategies 
is  the  need  to  manage^organizational  variety.  W.  Ross  Ashby 
in  Design  for  a Brain—  first  postulated  and  described  the  Law 
of  Requisite  Variety . Stafford  Beer  discusses  the  concept  further 
in  Brain  of  the  Firm  and  states  that  "control  can  be  obtained  only 
if  tfhe  variety  of  t he  controller  is  at  least  .as  great  as  the 
variety  of  the  situation  to  be  controlled." — / Specifically, 
variety  is  "the  total  number  of  possible  states  of  system  or  of 
an  element  of  a system." — ' How  is  this  relevant  to  our  pre- 
ceding discussion  of  distributed  data  base  technology? 

As  we  have  previously  noted,  distributed  data  base  tech- 
nology promotes  variety  generation  as  an  explicit  objective. 
Incremental  decision  making  may  allow  variety  generation  to 
outstrip  organizational  control.  Thus  a manager  is  bound  to 
an  inefficient  or  ineffective  strategy  without  recourse  to 
improvement.  Consequently  the  managers  might  back  themselves 
into  a no  win  situation.  However  a systematic  functional 
analysis  tied  to  the  concept  of  control  strategies  would  allow 
a manager  to  see  the  full  range  of  options  and  their  ensuing 
advantages  and  disadvantages.  Rational  decision  making  then 
becomes  closer  to  being  a reality.  It  is  this  sort  of  per- 
spective that  managers  in  the  middle  level  of  the  Navy's  data 
processing  environment  must  take.  It  is  imperative  that  their 
tasks  and  the  skills  that  they  bring  to  the  tasks  be  well 
defined  and  well  selected  because  these  managers  must  manage 
variety,  not  only  within  the  administrative  and  tactical  levels 
but  also  between  them.  In  our  view,  the  concept  of  requisite 
variety  presupposes  an  extensive  training  and  skill  development 
plan.  We  will  cite  the  need  for  such  a plan,  among  others,  in 
the  Solution  Strategy  section  that  concludes  this  report. 
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— For  a further  elaboration  on  this  discussion,  see  Captain 
J.  F.  Jenista,  "Navy  Command  and  Control,"  in  Trokop,  Ed., 
op.  cit.,  pp.  130-135. 

— ' Ashby,  W.  Ross,  "Design  for  a Brain,"  Chapman  and  Hall,  1952. 

— ^Beer,  Stafford,  "Brain  of  the  Firm,"  Herder  and  Herder,  1972, 
p.  53. 

— ^Beer , Stafford,  op.  cit.,  p.  307. 
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SOLUTION  STRATEGY 


The  first  step  in  our  proposed  solution  strategy  is  to 
adopt  a methodology  to  examine  functions,  dissect  them  into 
activities,  identify  the  information  processing  requirements, 
and  reassemble  the  activities  into  function  requirements,  thereby 
synthesizing  the  organizational  information  requirements.  This 
could  initially  begin  with  a prescribed  procedure  as  follows: 

1.  Identify  for  each  organization  its  essential  functions. 

2.  Examine  each  decision  function  in  terms  of  information 
required  in  order  for  activities  to  be  satisfactorily 
performed. 

3.  Examine  each  activity  in  terms  of  information  input, 
output,  storage  and  processing  related  to  time. 

4.  Identify  activity  to  activity  transfer  of  data. 

5.  Reassemble  the  activities  into  functions  which  should 
identify  the  information  requirements  of  the  functions. 

6.  Regroup  the  function  by  generic  type  (Intra,  Inter, 
or  External)  to  establish  the  information  interfaces 
of  the  command  and  the  requirements  of  organization 
for  information  technology. 

This  procedure  could  be  conducted  for  each  organization  and 
any  conflicts  resolved  by  cooperative  problem  solving  among 
the  organizations  (e.g.,  shift  a function  to  another  command; 
design  a compatible  interface;  provide  access  by  one  command 

of  another  command  data  base;  etc.).  j 

A.  Distributed  Data  Base  Network  Alternatives 

Once  the  organizational  information  requirements  have  been 
determined  and  the  appropriate  degree  of  decentralization 
determined,  the  next  step  will  be  to  look  at  the  distributed 
data  base  network  alternatives.  Networks  are  the  key  to  the 
interconnection  of  distributed  processing  elements  or  nodes. 

A network  system  can  be  designed  in  several  different  ways, 
none  of  which  is  absolute.  A private  network,  that  is  the 
communication  channels  used  by  one  specific  user,  probably  will 
reflect  the  structure  of  the  organization.  A distributed 
network  can  be  defined  as  "when  there  are  many  users  sharing 
several  application  programs  - and  the  .users  and  the  programs 
are  not  located  in  the  same  place — . — ' As  can  be  seen  this 
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definition  also  applies  to  the  term  of  distributed  processing, 
so  both  terms  do  relate  to  the  same  concept. 

A ring  network  (Figure  V-l)  consists  of  several  nodes, 
with  no  central  control,  linked  to  a communication  channel. 

Each  node  contains  a list  of  processing  capabilities,  some  of 
which  can  reside  in  one  or  more  nodes.  The  user  at  one  node 
only  addresses  a process  named  in  a message  which  travels  along 
the  bus  until  that  particular  process  is  found;  the  user  does 
not  have  to  know  which  of  the  nodes  perform  the  application. 

This  structure  is  considered  by  many  to  be  a truly  decentralized 
process . 

The  star  configuration  (Figure  V-2)  involves  a central 
processor  connected  to  each  of  the  nodes.  There  can  be  some 
data  base  distribution  as  well  as  processing  capabilities  at 
each  of  the  nodes,  but  all  communication  between  nodes  is  done 
through  the  central  site.  Here,  more  rigid  control  of  priority 
and  function  transfer  is  possible. 

These  are  two  typical  network  configurations.  Other 
alternatives  can  be  selected  or  devised. 

One  advantage  for  the  user  of  distributed  systems  is  that 
there  is  not  one  software  structure  to  which  users  of  the  system 
must  adhere.  However,  this  doesn't  mean  that  nodes  or  users  are 
completely  autonomous.  Each  node  must  be  compatible  with  other 
nodes  in  terms  of  transfer  of  data  or  processing  functions  in 
support  of  other  nodes  in  the  network.  A certain  degree  of 
centralized  control  must  be  present  if  the  organization  is  to 
maintain  any  control  over  its  goals  and  objectives.  This  can 
be  accomplished  by  means  of  an  orderly  analysis  of  information 
requirements  looking  towards  an  acceptable  overall  and  local 
orchestration  method. 

In  order  to  effectively  tackle  the  solution  strategy  we 
recommend  for  distributed  data  bases  and  processing,  it  will 
be  necessary  to  bring  key  Navy  management  personnel  together 
with  general  systems  specialists.  This  assemblage  must  work 
under  a common  taxonomy  of  problem  definition  and  solution. 
Hardware,  software,  and  data  base  structure  should  not  be 
permitted  to  govern  the  problem  definition  exercises  but  should 
only  be  looked  i<pon  as  tools  available  for  solving  information 
problems.  . 
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A third  stop  in  tho  solution  strategy  will  bo  to  draw  up 
an  extensive  training  and  skill  dovolopmont  conversion  plan  to 
cover  tho  olomonts  ot  tho  solution  that  has  boon  designed.  This 
training  will  cover  hardware,  sot t ware,  data  base  struct  tiro,  and 
other  aspects  ot  tho  system  tor  tho  various  categories  of  .special- 
ists. Tho  design  of  those  training  courses  will  bo  relatively 
simple  once  the  more  difficult  second  step  ot  solution  strategy  has 
been  worked  out.  As  a matter  ot  fact,  it  will  not  be  necessary 
to  design  all  ot  the  necessary  training  courses  from  scratch. 
Courses  are  already  in  existence  at  many  institutions  ot  highot 
learning,  as  well  as  at  certain  ot  the  service  schools  such  as 
the  Navy  "A"  and  "H"  Schools,  The  Defense  Systems  Management 
College,  Program  Management  Course,  The  Department  ot  Defense 
Computer  Institute  and  the  Navy  Post-Graduate  School  Software 
Engineering  Course  Scries  (sponsored  by  NAVFl.KX  and  the  Naval 
Research  Laboratory).  These  schools  and  courses  can  till,  in 
whole  or  in  part  some  of  the  training  requirements  we  envisage. 

A review  in  depth  ot  currently  available  courses  could  serve  as 
a point  of  departure  for  the  completion  of  a training  matrix  along 
the  lines  of  the  display  in  Figure  V t,  with  t ho  different  cate- 
gories of  training  personnel  shown  along  tho  top  ot  the  matrix  and 
the  course  subject  matter  shown  down  the  left-hand  side.  Currently 
available  courses  would  till  some  ot  t lie  boxes  in  the  matrix; 
where  boxes  then  remain  blank,  consideration  should  bo  given  to 
the  development  ot  now  courses  following  a prioritised  training 
development  plan. 

The  approach  described  above  is  definitely  feasible.  Its 
implementation  will  require  primarily  the  dedication  ot  the 
time  ot  those  key  Navy  management  personnel  and  general  systems 
consultants  who,  acting  in  concert , are  essential  to  its 
res l i seat  ion . 


''^Kuger,  Charles  11.,  "Analyzing  Distributed  Networks,"  Data 
Communicat  ions,  Vol  . (>.,  No.  H (August  t 7 7 ) . 
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This  selected  bibliography  is  grouped  into  three  main 
general  areas  developed  by  Data  Solutions  for  convenience  as 
shown  in  Figure  A-l.  The  first  category,  "Determining  Factors," 
answers  this  question:  What  is  DDP? ; What  is  the  logic  behind 
DDP? . The  second  category,  "Configuration,"  examines  the 
dynamics  of  distributed  data  processing  systems,  through  articles 
and  papers  describing  an  actual  model  or  describing  special 
equipment  to  do  a certain  job.  This  is  the  largest  section  and 
the  most  complex,  and  in  no  way  it  represents  a true  relationship 
of  subjects.  That  has  been  the  biggest  problem  in  assembling  this 
classification,  since  all  sections  and  subdivisions  are  part  of 
the  whole  picture. 

The  last  category,  "Applications,"  is  a compilation  of 
articles  that  describe  how  some  organizations  have  implemented 
some  forms  of  DDP. 

Many  of  the  articles  and  papers  touch  on  more  than  one  of 
these  categories,  so  a list  of  the  most  relevant  references 
from  the  selected  bibliography  has  been  listed  under  each  section 
of  the  classification  scheme.  The  last  category  does  not  have 
such  a list  since  it  would  refer  to  all  the  references  in  the 
bibliography  under  that  same  heading. 

A.  Determining  Factors 

This  category  presents  the  literature  of  a descriptive 
nature  on  the  subject  of  DDP  and  gives  an  insight  to  the  current 
trends  of  thought  on  the  present  state  of  the  art  and  what  would 
be  likely  to  develop  in  the  future.  This  section  is  subdivided 
into  three  parts:  Definition,  Adaptation  and  Security  and 
further  subdivided  as  shown  in  Figure  A-2. 

A. 1 . Definitions 

The  following  references  represent  comprehensive  material 
that  defines  and  describes  various  grades  of  distributed  data 
processing,  including  definitions  of  a network,  date  base, 
minicomputer. 

• "Distributed  Processing/Data  Communication",  Fortune, 

March  1977. 

• "Distributed  Data  Systems",  EDP  Analyzer,  June,  1976. 

• Down,  P.  J.  and  Taylor,  F.  E. , "Why  Distributed 
Computing?" 
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o Enslow,  Dr.  P.  H.  , "What  Does  'Distributed  Processing' 
Mean?" . 

• Lecht,  Charles  P.,  "The  Waves  of  Change",  Chapter  6. 

• Farber,  David  J.,  "Distributed  Data  Bases  - An 
Exploration" . 

• "Network  Structures  for  Distributed  Systems",  EDP 
Analyzer,  July  1976. 

• Hansen,  John  R. , "The  Shape  of  Things  to  Come". 

A. 2.  Adaptation 

This  section  deals  with  the  variety  of  arguments  and 
different  opinions  of  the  people  in  the  industry  in  favor  of 
centralized  systems  and  of  distributed  systems.  It  gives  an 
idea  of  what  are  the  major  advantages  and  disadvantages  of  DDP. 
Also,  it  evaluates  the  impact  that  distribution  would  have  upon 
the  structure  and  environment  of  an  organization  and  its  manage- 
ment personnel.  This  section  is  further  divided  into  two  parts. 

A. 2.1.  Environment  Factors 

The  articles  here  focus  on  the  managerial  and  organiza- 
tional structure  considerations  that  a company  studying  the 
feasability  of  a DDP  system  should  evaluate. 

• Champine,  G.  A.,  "Six  Approaches  to  Distributed  Data 
Bases" . 

• Bielec,  John  A.,  "Managing  the  Computer  Non-center  of 
the  Future". 

• "Centralization  Backs  Distributed  Users",  Computer 
World,  May  9,  1977,  Page  37. 

• "Consider  Future  Applications,  Measurable  Productivity", 
Minicomputer  News,  July  14,  1977,  Page  3. 

• "Distributed  Data  Systems",  EDP  Analyzer,  June  1976. 

• Hannan,  J.  and  Fried,  L.,  "Should  You  Decentralize?". 

® Keider,  Stephen  P.,  "Once  Again  - Centralize  or 
Decentralize ' . 
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• Kelley,  Neil  D. , "Distributed  Data  Processing:  Can 
You  Afford  a Disaster?". 

• LaVoie,  Paul,  "Distributed  Computing,  Systematically". 


o "New  Trends  in  Data  Processing",  Dunn's  Review, 

July  1977. 

• Patrick,  Robert  L.,  "Decentralizing  Hardware  and 
Dispersing  Responsibility". 

• Poppel,  Harvey  L. , "Distributed  Processing  Seen 
Lacking  Understanding". 

• Weber,  Richard,  "Decentralized  Processing  Has 
Advantages , Drawbacks " . 

• Feiderman,  Lawrence,  "It's  a Small  World". 

A. 2. 2.  Motivation 

These  articles  refer  to  the  contributing  factors  for 
distributed  processing.  They  give  an  idea  of  what  are  the 
major  advantages  and  disadvantages  of  DDP,  and  the  current 
and  future  trends. 

• "Distributed  Data  Systems",  EDP  Analyzer. 

• Hannan,  J.,  "Should  You  Decentralize?". 

• "The  Rationale  For  Distributed  Systems",  Infotech. 

• Joseph,  Earl  C.,  "Distributed  Processing  Architecture  - 
Past,  Present  and  Future  Trends",  Infotech. 

• Lecht,  Charles  P. , "The  waves  of  Change"  Chapter  6. 

• Luke,  John  W. , "Unraveling  the  Confusion  of 
Distributed  DP". 

o Spiro,  Kornel , "Computer  Systems  of  the  Future". 

• Smith,  Dr.  Walton  E.,  "Centralization  vs.  Decentraliza- 
tion" . 
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A. 3.  Security 


The  subject  of  security  has  been  separated  since  it  is  one 
of  the  principal  considerations  when  implementing  DDP , and  it 
is  used  both  to  attack  and  defend  the  concepts  of  centraliza- 
tion and  distribution.  This  section  is  subdivided  into  two 
parts  dealing  with  the  concepts  of  integrity  of  data  bases, 
retrievability  and  redundancy  of  the  system.  Also  it  examines 
the  methods  to  prevent  illegal  access  to  the  system. 

A. 3.1.  Methods 

Techniques  that  enhance  security  of  the  system. 

• Becker,  Hal  B.,  "Network  Security  in  Distributed  Data 
Processing" . 

• Grubb,  Dana  S.,  "System  Security". 

• Held,  Gilbert,  "Locking  Intruders  Out  of  a Network". 

• Karp,  Harry  R. , "Security  and  Radio  Links  Head  Up 
Research  List". 

• Down,  P.  J.,  "Why  Distributed  Computing?". 

• Spiro,  Kornel,  "Computer  Systems  of  the  Future", 

Page  29. 

o Yasaki,  E.  K. , "It's  a Question  of  Experience". 

A. 3. 2.  Charcteristics 

Articles  depicting  the  security  characteristics  of 
distributed  networks,  data  bases  and  the  aspects  of  communi- 
cation failure  and  recovery. 

© Farber,  David  J.,  "Distributed  Data  Bases  - An 
Exploration" . 

o Farber,  David  J.,  "A  Ring  Network". 

© Held,  Gilbert,  "How  Communication  Switches  Multiply 
Network  Options,  Part  2:  Improving  Availability". 

o Rugor,  Charles  II.,  "Eight  Factors  Aid  Network  Design 


and  User  Interface". 


© de  Smet,  Joe,  "'Pacuit'  Switching  Combines  Two 
Techniques  in  One  Network". 

B.  Configuration 

This  category  examines  different  methods  to  accomplish  a 
distributed  data  base  and  distributed  network  architectures  as 
shown  in  Figure  A-3.  The  major  sub-headings  are:  System  Structures; 
Small  Business  Systems;  Network  Operation  and  Communications. 

Articles  describing  the  configuration  of  small  business  systems, 
minicomputers  and  microprocessors.  Also  there  are  many  articles 
of  a technical  nature  that  give  a description  of  the  hardware 
components  in  a network,  and  the  protocol  techniques  used  in 
transmission  of  data.  The  last  subdivision  deals  with  articles 
on  future  expectations  of  data  communications  and  the  current 
services  offered  on  the  market  today.  This  section  is  subdivided 
into  four  parts. 

B.l.  System  Structures 

This  section  deals  with  the  problems  of  distributing  data 
bases  and  networks,  it  is  divided  into  these  2 categories. 


B.1.1. 


Data  Bases 


This  section  examines  articles  that  deal  with  some  actual 
experiences  and  also  theories  of  data  base  distribution. 

• Champine,  G.  A. , "Six  Approaches  to  Distributed 
Data  Bases". 


Maryanski , Fred  J, 
Data  Base  System". 


"A  Minicomputer  Based  Distributed 


• Farber,  David  J.,  "Distributed  Data  Bases  - An 
Exploration" . 

© "Distributed  Data  Systems",  EDP  Analyzer,  June  1976. 

• Severino,  Elizabeth,  "Databases  and  Distributed 
Processing" . 

• Foster,  John  D.,  "The  Development  of  a Concept  for 
Distributive  Processing". 

H.1.2.  Network  Structures 


The  network  is  an  intrinsic  part  of  any  communication 
system  and  plays  a very  important  role  when  "going  distri- 
buted". This  section  examines  the  different  designs  of 
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Configuration 


Figure 


network  architecture  from  the  centralized  system  to  configu- 
rations in  a distributed  system. 

• Lynch,  Arthur,  "Distributed  Processing  Solves 
Mainframe  Problems". 

• Ashenhurst,  R.  L. , "A  Hierarchical  Network". 

• Doll,  Dixon  R. , "Relating  Networks  to  Three  Kinds  of 
Distributed  Functions". 

• Blanc,  Robert  P. , "Computer  Networking". 

• Farber,  David  J.,  "A  Ring  Network". 

• Fraser,  A.  G. , "A  Virtual  Channel  Network". 

• Karp,  Harry  R.,  "Networks:  Future  is  Here  but 
Designers  Waiting". 

m "Network  Structure  for  Distributed  Systems",  EDP 
Analyzer. 

• Ruger,  Charles  H. , "Eight  Factors  Aid  Network  Design 
and  User  Interface". 

• Wolf,  Erie  W. , "An  Advanced  Computer  Communication 
Network".  (ARPA) 

• Wulf , William,  "A  Local  Network". 

B.2  Small  Business  Systems 

Under  this  heading,  there  arc  articles  and  papers  that 
deal  with  the  field  of  minicomputers,  microprocessors,  data 
entry  systems,  etc.  This  section  is  subdivided  into  three 
parts . 

B.2.1.  Characteristics 

Articles  of  a general  nature  describing  the  direct 
relationship  of  the  now  technology  (minicomputers)  and  DDP. 

• Anderson,  I..  H. , "Distributed  Intelligence 
Microcomputer  Systems  (DIMS)". 

• Feidelman,  Lawrence,  "Distributed  Computing  - It's  a 
Small  Woricl". 
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• Reagan,  Fonnie  H. , "Tho  Hicj  Promi a©  of  Small  Business 
Systems" . 

• Klolz,  William  II.,  "Combining  Data  Entry  With 
Dispersed  1)P". 

B.2.2.  Processors 


Those  articles  deal  with  the  characteristics  of  mini- 
computers and  microprocessors,  some  of  their  features  and  costs. 


n.2. 


• bowers,  Dan  M. , "Minicomputers  and  Microcomputers" . 

• Hansen,  John  R. , "The  Shape  of  Things  to  Come". 

• Bailey,  S.  J.,  "Put  Memories  in  Control;  Enhance 
Process  Response". 

• Yasaki,  E.  K. , "The  Mini:  A Crowing  Alternative". 

• Yasaki,  E.K.,  "The  Emerging  Microcomputer". 

3.  Now  Products 


This  section  contains  articles  that  describe  products 
offered  by  different  vendors  and  manufao  turor  a. 

• Options  Grow  for  Small  Business,  Distributed  Users". 

• Growth  of  Cobol:  Signal  of  Trend  to  Distributed  DP'?", 
a "MDS  Offers  Distributed  Processing  Systems". 

e "Computer  Starts  Family  of  Large-Memory  CRTs", 
e "Four-Phase  Word  Processing  System  Ties  32  Stations". 

• "DS/3000'  Lota  Users  Process  Data  on  Any  HP  3000-11 
in  Not". 

B.3.  Network  Operation 

A look  into  some  of  the  equipment  which  forms  part  of  a 
network,  such  as  modems  and  concentrators,  the  data  transfer 
channels  and  the  different  techniques  used  in  protocol.  This 
catogory  is  subdivided  into  two  parts. 


I 


i 


All 


H.3.I.  Protocol 


An  examination  of  switching  techniques,  packets,  messages, 
circuits. 


• Jenny,  Christian  J. , "Distributed  Processing  Within 
an  Integrated  Circuit/Packot-Switching  Node". 

• "Network  Structures  for  Distributed  Systems",  FDP 
Analyzer . 

• Nichols,  Patrick  J. , "General-Purpose  Protocol 
Integrates  Different  Networks". 

• Sharp,  Duane  E.,  "Combined  Traffic  Flows  Quickly  on 
Packet-Switched  Network  Systems". 

• de  Smat,  Joe,  "'Pacuit'  Switching  Combines  Two 
Techniques  in  One  Network". 

n.3.2.  Components 

This  section  deals  with  the  physical  or  hardware 
requirements  that  link  nodes  in  a network.  It  is  divided  into 
two  parts. 

B.3.2.1.  Interface  Equipment 

A brief  incursion  into  the  area  of  modems,  multiplexens 
and  concentrators. 

• Greer,  Curtis  L. , "Designing  a Least-Cost  Network  With 
Split-Channel  Modems". 

• Held,  Gilbert,  "Sharing  at  the  port:  An  economical 
Way  to  Reach  the  Host". 

• Geld,  Gilbert,  "How  Communication  Switches  Multiply 
Options,  Part  2:  Improving  Availability". 

• Nichols,  Patrick  J. , "General-Purpose  Protocol 
Integrates  Different  Networks". 

• Huger,  Charles  I!.,  "Eight  Factors  Aid  Network  Design 
and  User  Interface". 

• Lyon,  David  L.,  "Testing  Modem  Performance  in  Polled 
Operation" . 
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• "Network-Cont rol  System  Provides  Modem  Supervision 
for  Monitoring,  Diagnosis,  Rerouting",  Data 
Commti  nications. 

• Riviere,  Charles  J.,  "How  Concentrators  Can  Be 
Message  Switchers  As  Well". 

C.  Communications 


C.l.  Data  Transmission  Services 

An  overview  of  commercial  network  services  available  in 
the  market  and  what  the  user  can  expect  in  the  near  future. 

• "Data  Networks",  1974  IDEE  Intercon  Technical  Papers. 

• Lecht,  Charles  P.,  "The  Waves  of  Change",  Chapter  V. 

• Piatowski , Thomas  F. , et.  al.,  "Inside  IBM's  Systems 
Network  Architecture". 

• "SNA  Survival  Short,  Expert  Predicts",  Computerworld, 
August  15,  1977,  Pago  23. 

• Caswell,  Stephen,  "Satellite  Business  Systems:  The 
Start  of  Something  Big". 

• "Communications  Satellite  Corp. " , Financial  World, 
March  1,  1977,  Page  16. 

• "The  Dorns  at.  War  Gets  Tougher  and  Costlier",  Dunn's 
Reviow,  May  1977,  Page  72. 

• Uttal,  Bro,  "IBM  Roaches  for  a Golden  Future  in  the 
Heavens" . 


C.l. 2.  Data  Buses 

Technological  descriptions  of  data  buses,  also  called 
data  highways,  and  the  development  of  new  .lines  of  communi- 
cations ouch  as  coaxial  cable,  filier  optics,  microwave. 

• "Alternate  Mode  Outlined  for  High-Speed  Transmission", 
Computerworld,  June  13,  1977,  Page  81. 

• Androiev,  Nikita,  "In  Quest  of  a Common  Data  Bus". 

• Androiev,  Nikita,  "A  Closer  Look  at  Data  Bus  Systems". 
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"Bankers  Trust  Pioneering  With  Fiber  Optic  Cable", 
Data  Communications,  August  1977,  Pago  16. 
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• Reese,  Irving,  "Fiber  Optic  Data  Bus  for  Control  - A 
Reality! " . 

C.2.  Trends  and  Projections 

These  articles  describe  the  future  of  communications 
and  the  need  for  standardization. 

• Cerf,  Vinton  G. , "The  Future  of  Computer  Communica- 
tions" . 


• Faber,  David  and  Baran,  Paul,  "The  Convergence  of 
Computing  and  Telecommunications  Systems". 

• Ferreira,  Joseph  and  Nilles,  Jack  M. , "Five-Year 
Planning  for  Data  Communications . 

• "Harold  C.  Folts,  Government  Engineer  is  working 
quietly,  but  firmly  to  push  for  interface  standards". 
Data  Communications,  August  1977,  Page  29. 


>lications 


This  last  category  of  the  bibliography  contains  articles 
on  commercial  and  government  organizations  which  have  imple- 
mented some  form  of  distributed  data  processing  on  the 
financial  sector  as  well  as  the  technical  side.  The  sub-headings 
under  this  classifications  could  take  the  form  shown  in  Figure  A-4. 
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